The Simulation Engine
The core of PetroVR is its Simulation Engine. Simulation systems base their design on a simple premise: build a virtual world where each and every entity of the modeled domain is represented by a virtual counterpart, and then run it so that each virtual counterpart will play a role equivalent to that of the entity in the real world. Thus, the virtual model aims at being governed by the same rules as reality.
The better all fundamental entities and their behavior are captured, the more accurate the model will be. An accurate model mimics reality successfully so that conclusions can be drawn from observations in the virtual world - insofar as the model is accurate, these conclusions will also be valid for the real world.
In the case of PetroVR, the world has entities such as reservoirs, fluids, rigs, wellbores, well completions and facilities. As the sum of these entities makes up the model (which is identified as an individual PetroVR project), we call them model objects.
The Pulse of the Simulation
The PetroVR simulation is not static; the notion of time and progression is essential. Things happen with the passing of time and the virtual entities update their state based on the current date, taking the actions specified in the rules that dictate their behavior, and generally determined by events that have already happened on the timeline.
For instance, when the date scheduled to start drilling a well arrives, the simulation engine will start the drilling process but only if there is a rig unit available (for a variety of reasons it may not be so); when this condition is met, the rig will perform the drilling. Wells will start producing once they have been drilled and all their downstream facilities are built and ready to go. Also, the passing of time will make the fluids flow, and the facilities will declare themselves in excess if they receive more fluid than their capacity permits. If this happens, chokes will be applied to the affected wells, or other excess policies will be applied. Other events that may take place are splits or re-routings - in sum, any circumstance may trigger a predefined action as the simulation evolves, and these new changes in the state of actors can in turn affect other entities, according to the specific rules that apply to each.
Activities that involve model objects are organized as Jobs in a Schedule, with their own duration and specific Costs (CapEx and OpEx). The rules that govern their execution are entered as start conditions: for instance, a drilling job will start when a unit of its assigned rig becomes available, and facility expansions take place as capacities are exceeded.
Another feature that makes the simulation approach especially valuable is the calculation of the routing of fluids - the precise, day-by-day tracking of fluid rates and cumulative amounts at any point of the system.
The report periodicity, defined in the General Tab, determines the granularity or level of detail of simulation results by establishing the length of the reporting periods. Actors in the simulated world keep track of their production and expenditure. Depending on the selected granularity, a "photograph" is taken at the end of each period to capture a checkpoint in the expenditure history of all entities that spend money and in the production history of all entities that produce fluids. The pace at which the world timer ticks (to simulate the passing of time) is independent from the periodicity. There is a tick each day throughout the whole life of a project, whereas report photographs are usually taken monthly, quarterly or yearly according to the selected periodicity.